A standard part of the design process for leading edge system on chip (SoC) designs is to create a prototype of the design before it is fabricated to silicon. This prototype can take several forms depending upon the design problem being addressed. It is not unusual for multiple prototypes to be created of the same design in order to best address specific design issues. There are two primary types of prototypes: physical prototypes and virtual prototypes.
Physical prototypes are typically either hardware emulators or Field Programmable Gate Array (FPGA) prototypes. Hardware emulators, such as the Cadence® Palladium® verification computing platform from Cadence of San Jose, Calif., the Veloce verification system from Mentor Graphics of Wilsonville, Oreg., or the EVE ZeBu-Server system emulator from Synopsys, Inc. of Mountain View, Calif., for example, model the behavior of the SoC design using a collection of custom processors or FPGAs. To develop a physical prototype, the hardware design for the SoC is compiled from its hardware design language (HDL) into a custom representation which is then downloaded into the physical prototype for execution.
Virtual prototypes form a software-only representation of a system on chip design. Depending upon the accuracy of the virtual prototype, it can execute at a full range of speeds. The virtual prototype can execute much faster than the actual hardware which it represents or much more slowly in cases where the virtual prototype is more accurately representing the behavior of the underlying hardware. The virtual prototype typically contains a collection of virtual prototype models, each virtual prototype model representing the various hardware components in the SoC design being modeled.
Whereas a hardware prototype necessarily represents all of the functionality of the modeled components, this is not necessarily true for virtual prototypes. It is common practice to abstract the timing details of a virtual prototype model in order to achieve faster execution speed. In some cases, the functionality of a virtual prototype model may also be abstracted to achieve faster performance or shorten model development time. Each component may be modeled at a different level of timing or functional accuracy depending upon the needs of the designer.
Depending upon the abstraction level of the individual models, virtual prototypes may be used at various points during the SoC design cycle. Accurate virtual prototypes can be used to perform architectural analysis, semiconductor intellectual property (IP) core selection and firmware development. A virtual prototype which does not have timing accuracy would likely not be used in this case due to lacking sufficient design detail. Higher speed, more abstract virtual prototypes can boot an operating system and execute application code, all before actual silicon is fabricated. While accurate virtual prototypes may be used for these tasks as well, it is rarely done due to the much slower execution times.
The accuracy of a virtual prototype type depends upon the accuracy of the virtual prototype models it contains. Indeed, there can be multiple virtual prototype models at different levels of abstraction contained in the same virtual prototype. Accuracy in this case does not typically refer to the functional accuracy of the prototype but more to the timing of the system. Most virtual prototypes will represent all of the functionality of the modeled component but with varying levels of timing accuracy. Most virtual prototypes are written based upon the transaction-level modeling (TLM) standard, produced by the Accellera Systems Initiative of Napa, Calif. and incorporated into the Institute of Electrical and Electronics Engineers Standards Association (IEEE-SA) 1666 standard for SystemC™. The TLM specification describes coding guidelines for a loosely-timed (LT) and approximately-timed (AT) level of abstraction. In a loosely timed virtual prototype, the models contained in the virtual prototype will either be completely untimed or will correlate their timing to actual execution time only at transaction boundaries. In an approximately timed virtual prototype, the virtual prototype model typically correlates to the system time at the boundary of every transaction and will often include additional timing information for actions which occur in the middle of a transaction. Commercially available loosely timed models include the Fast Models for ARM® (ARM Holdings of Cambridge, UK) and the Open Virtual Platforms™ (OVP™ of Oxfordshire, UK) designed by Imperas™ Software of Oxfordshire, UK.
Additionally, there are cycle accurate (CA) virtual prototypes which completely model the behavior of the underlying hardware. These models can either be hand-written to model this behavior and then validated against the actual design, or created automatically from the HDL representation of the component. For example, some commercially available cycle accurate virtual prototype models are created directly from HDL using the Carbon Model Studio product from Carbon Design Systems of Acton, Mass.
LT models execute quickly but do not contain sufficient timing detail to enable their use to make hardware design decisions. CA models are accurate enough to be used to make hardware design decisions but execute too slowly to be useful for software development. There is a need for a solution which provides adequate speed for aiding in software development, while providing accurate analysis for validating the behavior of the underlying hardware.